-
-
Notifications
You must be signed in to change notification settings - Fork 445
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate a reusable Image class from Screen #834
Conversation
…Added Canvas methods for drawing Pixels/Images directly
Excellent! I like it! |
Okay, but don't merge it yet, I'll add tests for it, as well as some bug fixes. I'll add a couple of more commits to this one :) |
include/ftxui/screen/box.hpp
Outdated
@@ -15,6 +15,7 @@ struct Box { | |||
static auto Intersection(Box a, Box b) -> Box; | |||
static auto Union(Box a, Box b) -> Box; | |||
bool Contain(int x, int y) const; | |||
int Area() const noexcept; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FTXUI already ban using C++ exception. I would remove the noexcept
here, because it feel superfluous and inconsistent with every other functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about adding Width()
and Height()
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted about noexcept
I can add Width()
and Height()
also, but it is often used like if (Width() > 0 and Height() > 0)
when checking boxes, so i decided it would be most convenient to check it through the area, with the added benefit of checking for negatives
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about Area::IsEmpty()?
(I pushed a patch for adding it instead)
include/ftxui/screen/image.hpp
Outdated
@@ -0,0 +1,87 @@ | |||
// Copyright 2020 Arthur Sonzogni. All rights reserved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2024
include/ftxui/screen/image.hpp
Outdated
/// @brief A unicode character and its associated style. | ||
/// @ingroup screen | ||
struct Pixel { | ||
Pixel() | ||
: blink(false), | ||
bold(false), | ||
dim(false), | ||
inverted(false), | ||
underlined(false), | ||
underlined_double(false), | ||
strikethrough(false), | ||
automerge(false) {} | ||
|
||
// A bit field representing the style: | ||
bool blink : 1; | ||
bool bold : 1; | ||
bool dim : 1; | ||
bool inverted : 1; | ||
bool underlined : 1; | ||
bool underlined_double : 1; | ||
bool strikethrough : 1; | ||
bool automerge : 1; | ||
|
||
// The hyperlink associated with the pixel. | ||
// 0 is the default value, meaning no hyperlink. | ||
// It's an index for accessing Screen meta data | ||
uint8_t hyperlink = 0; | ||
|
||
// The graphemes stored into the pixel. To support combining characters, | ||
// like: a?, this can potentially contain multiple codepoints. | ||
std::string character = " "; | ||
|
||
// Colors: | ||
Color background_color = Color::Default; | ||
Color foreground_color = Color::Default; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While you are here, this might deserve its own file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(done)
src/ftxui/dom/canvas.cpp
Outdated
for (int py = y; py < yend; ++py) { | ||
for (int px = x; px < xend; ++px) { | ||
Cell& cell = storage_[XY{px, py}]; | ||
cell.type = CellType::kText; // Epixu: should we add kCustom or something? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kText sounds appropriate to me. We are covering the whole cell.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But kText
seems a bit weird in that context, probably rename those to:
CellType::BrailleSegment
, CellType::BlockSegment
, and CellType::Uniform
?
Probably doesn't matter too much, but still?
Because I'm having some ideas about drawing text, but large and segmented, like big ASCII letters. Here's an example:
_ ____ ____ ___ ___ _ _ _ _ _
/ \ / ___| / ___|_ _|_ _| / \ _ __| |_ / \ _ __ ___| |__ (_)_ _____
/ _ \ \___ \| | | | | | / _ \ | '__| __| / _ \ | '__/ __| '_ \| \ \ / / _ \
/ ___ \ ___) | |___ | | | | / ___ \| | | |_ / ___ \| | | (__| | | | |\ V / __/
/_/ \_\____/ \____|___|___| /_/ \_\_| \__| /_/ \_\_| \___|_| |_|_| \_/ \___|
Thanks for the support, I'm sorry that I'm a bit slow on this, but I've got a lot of stuff on my backlog |
Merged! Thanks for your patience! |
Nice 3D renderer ! |
Co-authored-by: ArthurSonzogni <sonzogniarthur@gmail.com>
Co-authored-by: ArthurSonzogni <sonzogniarthur@gmail.com>
Context:
I'm making a custom ASCII rasterizer of sorts, and I needed direct control on what's rendered to a Canvas. So I took the liberty to make some changes:
Main changes:
Example use case:
Secondary changes:
a. Added Box::Area method for convenience
b. .gitignored autogenerated directory by MSVC's CMake integration
Considerations:
I did run the tests on windows 10, they sometimes run, sometimes fail at these interrupt tests, not sure if this is normal or not:
FTXUI/src/ftxui/component/screen_interactive_test.cpp
Lines 34 to 51 in ce5ac6b
Additional notes:
I might be doing more occasional pull requests in the future, including regarding my issue #778 - I have a couple of optimizations in mind for the near future. If you think these changes are out of the scope of your library and don't need the spam, inform me and I'll stick to a fork!
All the best,
Dimo Markov